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PROCEDE DE REMONTEE AUTOMATIQUE DES EXIGENCES DE 
MODELES UML ET DE LEUR MISE A JOUR 

La presente invention se rapporte a un precede de remontee automatique des 
exigences de modeles UML crees par un outil de modelisation, et de leur mise a jour. 

Lorsque l'on modelise un projet, quel qu'il soft, on utilise actuellement, de 
facon preferentielle le langage UML, mis en oeuvre dans un outil de moderation, tel 
que « RHAPSODY » de la societe I-LOGIX. La moderation necessite la prise en 
compte d'exigences, et a cet effet, on dispose d'un outil de gestion d'exigences tel 
que « DOORS » de la societe TELELOGIC. Toutefois, il n'existe aucun moyen 
permettant d'assurer la tracabilite des informations du modele pour en informer 
I'outil de gestion d'exigences. 

La presente invention a pour objet un precede de remontee automatique des 
exigences de modeles UML vers un outil de gestion d'exigences pour permettre leur 
mise a jour, et ce, sans limitation sur la pose d'exigences et leur nombre. 

Le precede conforme a l'invention est caracterise en ce que l'on cree les 
exigences lors de la creation des elements du modele UML, qu'une fois le modele 
stabilise, on exporte vers I'outil de gestion d'exigences les exigences saisies dans le 
modele et l'on cree automatiquement un module de navigation contenant tous les 
objets UML pointes par au moins une exigence et un module d'exigences de niveau 
n. Avantageusement, on lie le module d'exigences de niveau nam autre module 
d'exigences amont de niveau n+1 defini precedemment. 

La presente invention sera mieux comprise a la lecture de la description 
detaillee d'un mode de realisation, pris a titre d'exemple non limitatif et illustre par 
le dessin annexe, sur lequel : 

- la figure 1 est un bloc-diagramme simplifie d'un exemple de mise en 
oeuvre du precede de l'invention, 

- la figure 2 est un diagramme illustrant la premiere importation d'un 
modele UML dans un gestionnaire d'exigences, selon le precede de 
l'invention, 

- la figure 3 est un diagramme illustrant une nouvelle importation , 
dans les memes conditions (import niveau 1) qu'en figure 2, 
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- la figure 4 est un diagramme illustrant une nouvelle importation d'un 
modele UML, mais a un niveau different (niveau 2) de celui de la 
figure 3, 

- la figure 5 est un diagramme illustrant la pose automatique de liens 
de traeabilite depuis le module vers d'autres modules DOORS selon 
le procede de Pinvention, 

- la figure 6 est un diagramme en quatre etapes, illustrant les operations 
successives intervenant lors d'une nouvelle iteration d'import d'un 
modele UML dans un gestionnaire d' exigences, selon le procede de 
Pinvention, et 

- les figures 7 et 8 sont des diagrammes montrant deux etats d'un 
module d'Exigences du gestionnaire d'exigences, respectivement 
avant et apres une nouvelle importation, selon le procede de 
Pinvention. 

On a represente en figure 1 les principaux elements de Parchitecture du 
systeme mettant en oeuvre Pinvention. Ces elements sont : un modeleur UML (1), 
qui est, de preference, Poutil « RHAPSODY », un outil (2) de gestion d'Exigences 
UML, qui est, dans le cas present, Poutil « DOORS , un atelier d'utilitaires (3), qui 
est ici « DOORS Custom » de la societe THALES AVIONICS » et un connecteur 
universel de connexion inter-outils (4) « PAPEETE » (faisant Pobjet d'une demande 
de brevet de la societe THALES); L'importation de modeles UML dans Poutil 
DOORS depuis Poutil RHAPSODY se fait de la maniere suivante. 
Lors de la premiere importation d'un modele UML de RHAPSODY vers DOORS 
(voir figure 2), il y a creation de deux modules dans DOORS: 

- Un module (5) d'Exigences UML_DOORS correspondant au niveau de 
specification (niveau 1 pour Pexemple represente). Ce module de DOORS 
contient Pensemble des Exigences UML_DOORS qui represented les 
Exigences UML stereotypies avec le niveau de specification choisi lors de 
l'importation. Ce module 5 contient ici les exigences de niveau 1 du modele. 
Ces exigences sont, pour cet exemple : HLR_01, LLR_01 et HLR_03. 
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- Un Module de navigation UML (Surrogate Module UML) (6) : ce module de 
DOORS contient une representation de P ensemble des elements UML du 
modele cree dans RHAPSODY. Cette representation est sous forme de 
reference vers les elements UML. Ce module a comme objectif de permettre 
la navigation entre RHAPSODY et DOORS (comme expose dans le manuel 
« DOORS Custom User Guide »). 
Les importations suivantes du meme modele UML peuvent etre de deux types 
differents. Soit, comme represent sur 1'exemple de la figure 3, il s'agit du meme 
niveau de specification que precedemment (niveau 1 en 1' occurrence). Dans ce cas, a 
la fois le Module d'Exigences UML_DOORS et le Module de navigation UML sont 
mis a jour en fonction des modifications apportees au modele UML. Soit, comme 
represente en figure 4, ils portent sur un niveau de specification different (niveau 2 
en l'occurrence, pour lequel il s'agit des exigences HLR_02 et LLR_02 ) . Dans ce 
cas, il y a creation d'un module d'Exigences UML_DOORS correspondant au niveau 
de specification selectionne (niveau 2) lors de l'importation et mise a jour du Module 
de navigation UML en fonction des modifications apportees au modele. 

Les liens entre une Exigence UML-DOORS et sa representation dans le Module 
de navigation UML sont crees automatiquement lors de l'importation du modele 
UML sous DOORS. Ces liens permettent la navigation entre les deux outils 
RHAPSODY et DOORS. 

La creation de liens vers d'autres modules d'exigences DOORS est realisee de la 
facon suivante. Apres avoir effectue une importation d'un modele RHAPSODY dans 
DOORS, il est possible de creer automatiquement les liens entre des Exigences du 
module cree automatiquement et des Exigences d'un autre module DOORS ou celles 
d'un autre module cree automatiquement anterieurement. Cette creation automatique 
de liens est effectuee avec 1'utilitaire DOORS TREK « Create links by key ... ». 
Ainsi, comme represente en figure 5, lors de l'importation du niveau de specification 
X, on cree des liens de tracabilite entre le module d'Exigences de niveau X et, d'une 
part, le module d'exigences de niveau X-l, et d'autre part un module de niveau de 
specification d'exigences tout a fait autre (SSS dans ce cas) . 
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La gestion des modifications apportees aux exigences relatives au modele UML 
est realisee de la facon suivante. 

La gestion des modifications des exigences sous-entend la capacite de naviguer 
entre l'outil RHAPSODY et l'outil DOORS. En effet, il faut etre capable d'analyser 
rapidement l'impact de modifications des exigences amont sur le modele UML afin 
d'appliquer les modifications adequates sur les elements mis en cause par cet impact 
et inversement. 

Pour realiser la modification d'Exigences UMLJDOORS, il ne faut pas modifier 
sous DOORS les attributs des Exigences UML_DOORS specifies dans les 
Exigences UML (comme explique dans le Guide de modelisation UML des 
exigences). Ces modifications ne doivent etre effectuees que dans le modele UML 
sous RHAPSODY. 

A la suite d'une modification d'Exigences DOORS, il faut pour chaque 
Exigence UML-DOORS qui la raffme (comme explique dans le Guide DOORS) : 

1 . naviguer, a l'aide de l'outil de navigation DOORS/RHAPSODY, vers l'Exigence 
UML associee, 

2. analyser 1' impact sur la modelisation de la modification a effectuer, 

3 . mettre a j our le modele 

4. mettre a jour l'Exigence UML dans le modele, 

5. importer le modele modifie sous DOORS, 

6. mettre a jour les attributs de gestion des exigences sous DOORS, 

Toute modification de modele doit etre effectuee en prenant en compte les 
Exigences UML qui ont une repercussion sur les elements modifies de maniere a 
maintenir la coherence entre les Exigences UML et le modele UML. 

Pour ce faire, il faut consulter pour chaque element UML modifie I'ensemble des 
Exigences UML qui ont une repercussion sur lui, pour verifier que ces exigences 
sont toujours coherentes avec la modification effectuee sur l'element. 

Pour gerer les evolutions d'un modele se traduisant par des modifications 
successives, on examine d'abord le mecanisme d'importations successives. 
L'importation d'un modele UML sous DOORS est effectuee en plusieurs etapes. Ces 
etapes sont invisibles pour 1'utilisateur, car elles sont effectuees en une seule fois lors 
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de l'importation. On a illustre en figure 6 les principals etapes de ce mecanisme 
d'importations successives. Cette figure comporte quatre diagrammes (references 1 a 
4). 

A l'etat initial (1), on a, dans DOORS, un module Exigences UMLJDOORS lie 
a un module de navigation UML (par des liens de navigation), ces modules generes 
automatiquement lors d'un import anterieur sont qualifies d' « anciens ». 

Lorsqu'arrive une demande d' importation du modele UML visant une mise a jour 
de ces deux modules, les actions suivantes sont engagees : 
creation de deux nouveaux modules (2): 

o un Module Exigences UML_DOORS contenant I'ensemble des 
Exigences UML_DOORS correspondant a toutes les Exigences UML 
contenues dans le nouveau modele UML importe, 
o un module de navigation UML representant le nouveau modele UML, 

- suppression de l'ancien module de navigation UML et de tous les elements 
DOORS le concernant, (3), 

- analyse des mises a jour a effectuer entre les deux Modules Exigences 
UML_DOORS, 

- mise a jour de l'ancien Module Exigences UMLJDOORS (4), 

- suppression du nouveau Module Exigences UMLJDOORS (4), 

- creation des liens de navigation entre l'ancien Module Exigences 
UMLJDOORS et le nouveau Module de navigation UML. 

L'utilisateur doit ensuite mettre a jour les liens de tracabilite avec les exigences 
amont. Cette etape n'est pas incluse dans l'importation du modele UML, mais doit 
etre effectuee separement apres chaque importation a l'aide de l'utilitaire DOORS 
TREK « Create links by key . . . ». 

La gestion des evolutions peut concerner ensuite 1'ajout d'exigences. Si 1'on 
ajoute une Exigence UML dans le modele, il y aura, lors de l'importation suivante, 
pour un meme niveau de specification, et un meme modele UML, creation d'un 
nouvel. objet DOORS dans le Module de navigation UML et dans le Module de 
navigation UML correspondants. 

A titre d'exemple simplifie, on a represents en figure 7 l'etat du Module 
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Exigences UML_DOORS avant une nouvelle importation, et qui comporte Ies 
Exigences EXI01 a EXI_04 (en version vl). On a represents en figure 8 1'etat de ce 
Module apres une nouvelle importation, EXI_02 etant modifiee (versions vl et v2 
coexistantes), et avec une nouvelle Exigence EXI_05 (version v2). 

De meme, si une Exigence UML deja importee lors d'une precedente importation 
est supprimee dans le modele, lors de Pimportation suivante, l'Exigence UML- 
DOORS correspondant a l'Exigence UML , ne sera pas supprimee du Module 
Exigences UML_DOORS, mais prendra le statut « OBSOLETE » et tous ses liens 
DOORS seront detruits. 

. Si une Exigence UML deja importee lors d'une precedente importation est 
modifiee dans le modele, il y aura, lors de l'importation suivante, : 

- creation d'une nouvelle Exigence UML-DOORS correspondant a l'Exigence 
UML 

- creation d'un lien entre 1'ancienne et la nouvelle Exigence UML-DOORS 

- transfert des liens entrants et sortants de 1'ancienne vers la nouvelle Exigence 
UML-DOORS 

- mise a jour du numero de version sur la nouvelle Exigence UML-DOORS 
par rapport a 1'ancienne. 

On obtient ainsi un historique des modifications d' exigences. 

En conclusion, le procede de 1'invention permet de remonter 
automatiquement sous DOORS toutes les informations de traeabilite rentrees dans le 
modele UML. II organise automatiquement sous DOORS tout le processus 
necessaire a la navigation entre les deux outils via le connecteur PAPEETE ou un 
lien XML (ou equivalent) . Enfm il organise automatiquement toute la mise a jour 
des modules lors des differentes evolutions du modele UML. 
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REVINDICATIONS 

1. Procede de remontee automatique des exigences de modeles UML 
creees par un outil de moderation, et de leur raise a jour , caracterise 
en ce que l'on cree les exigences lors de la creation des elements du 
modele UML, que, lorsque le modele est stabilise, on exporte vers 
l'outil de gestion d'exigences les exigences saisies dans le modele, et 
que Ton cree , automatiquement, un module de navigation contenant 
tous les objets UML pointes par au moins une exigence et un module 
d'exigences de niveau n. 

2. Procede selon la revendication 1, caracterise en ce qu'on lie le 
module d'exigences de niveau n a un autre module d'exigences 
amont de niveau n+1 defmi precedemment. 

3. Procede selon la revendication 1 ou 2, caracterise en ce que, lors de 
modifications d'exigences, on effectue ces modifications dans le 
modele UML, avec l'outil de modelisation. 

4. Procede selon Tune des revendications precedentes, caracterise en 
ce que l'outil de modelisation est « RHAPSODY » et que l'outil de 
gestion des exigences est « DOORS ». 

5. Procede selon la revendication 4, caracterise en ce que lors 
d' importations successives, on realise les etapes suivantes : 

- creation de deux nouveaux modules : 

■ un Module Exigences UML_DOORS contenant l'ensemble 
des Exigences UMLJDOORS correspondant a toutes les 
Exigences UML contenues dans le modele UML importe, 

a un module de navigation UML representant le nouveau 
modele UML, 

- suppression de l'ancien module de navigation UML et de tous les 
elements DOORS le concernant , 
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- analyse des mises a jour a effectuer entre les deux Modules 
Exigences UMLJDOORS, 

- mise a jour de l'ancien Module Exigences UML_DOORS, 

- suppression du nouveau Module Exigences UMLjDOORS, 

5 - creation des liens de navigation entre l'ancien Module Exigences 
UML_DOORS et le nouveau Module de navigation UML. 
. 6. Procede selon la revendication 4 ou 5, caracterise en ce que si une 
Exigence UML deja importee lors d'une precedente importation est modifiee 
dans le modele, il y aura, lors de 1'importation suivante, : 
10 ° creation d'une nouvelle Exigence UML-DOORS correspondant a 

1' Exigence UML 

o creation d'un lien entre I'ancienne et la nouvelle Exigence UML- 
DOORS 

o transfert des liens entrants et sortants de I'ancienne vers la nouvelle 
1 5 Exigence UML-DOORS 

o mise a jour du numero de version sur la nouvelle Exigence UML- 
DOORS par rapport a I'ancienne. 
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